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SEARCHING WITH ADAPTIVELY CONFIGURABLE USER 
INTERFACE AND EXTENSIBLE QUERY LANGUAGE 

Copyright Notice and Permission 

A portion of this patent document contains material subject to copyright protection. The 
5 copyright owner has no objection to the facsimile reproduction by anyone of the patent document 
or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, 
but otherwise reserves all copyright whatsoever. The following notice applies to this document: 
Copyright © 1999, Microsoft, Inc. 

Technical Field 

10 The present invention concerns data stores, graphical user interfaces, and query 

languages, particularly, interfaces and query languages. 

Background 

Data stores, or more particularly databases, generally store files of various forms or 
structures. Search programs, sometimes called search engines, allow users to use a query 
1 5 language to identify and retrieve these files or specific portions of files based on content-based 
search criteria. 

Although search engines and query languages have conventionally been focused on text 
files, recent years have seen an increasing need to search other file types, particularly in software 
development contexts. Seminal examples of file types in the development context include bugs, 

20 links, and components. A bug is an abstract data element that refers to a problem report, 

malfunction, defect, or other related issue regarding software code. A link is a data element 
identifying a logical association between two or more other data elements or objects, for example 
two or more duplicate or dependent bugs. Component-type files generally include re-useable 
software objects, including, for example, binary code, HTML code, source code, and so forth. 

25 Each of these file types often requires a specialized search engine, because they are 

disparate in form, content, and attributes, they are often stored in different databases, and users 
have different needs when searching these files than typical text files. Moreover, many of these 
search engines have a unique graphical user interface tailored to search its associated file types. 
Thus, for example, a user interface for searching bug files generally includes an arrangement of 
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input fields, which is entirely different than those in an interface for searching component files. 
Because of their disparate input-field arrangements, these unique user interfaces force users to 
continually reorient themselves as they switch from interface to interface to initiate searches for 
desired files of different types. 
5 Some interfaces, particularly OLE DB (Object Linking and Embedding Database) 

interfaces, provide a measure of commonness or congruence across distinct databases. However, 
these are limited to defining keyword searches, leaving the bulk of the disparate-interface 
problem unsolved. 

Additionally, many of these user interfaces use different query structures, with each query 
10 structure optimized for a particular its associated file type. To address this problem, many 
databases and associated search engines have begun "speaking" a common query language, 
known as SQL, which reduces the need for users to understand multiple query languages and 
formats. Although SQL (frequently read and pronounced as "se-kwel") has a broad range of 
query properties for searching many file types, its universe of properties and types cannot be 
15 readily expanded. Thus, any given version of SQL cannot adapt to search new file types that 
would require or benefit from new query-language features or properties. 

Accordingly, the present inventors identified an unmet need for adaptively configurable 
user interfaces for searching different types of data stores and an unmet need for a readily 
extensible or expandable query language. 

20 

Summary 

To address these and other problems, the inventors developed an adaptively configurable 
user interface to facilitate a common user experience across two or more data classes and an 
extensible common query structure to allow expansion of a query language to meet the demands 

25 of new data classes. An exemplary embodiment of the adaptively configurable interface includes 
a constant portion with one or more input fields (for example, team name, work area, data type, 
and folder) and an adaptive portion which changes to meet query properties communicated by 
particular search providers. Once a query is input, the adaptive interface translates it into a 
common parse tree, which it passes to one or more of the search providers. Which, in turn, map 

30 the parse tree onto their own particular query structures before processing. (Some embodiments 
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pass the query in text form to the search providers.) 

An exemplary embodiment of the extensible query structure includes a discovery 
mechanism for determining whether a database supports or requires use of non-standard query 
operators and value types. Thus, rather than making assumptions about the query language of a 
5 search provider, the exemplary embodiment communicates with the search provider to determine 
what language- features it supports, allowing the search provider to extend any existing query 
language or to provide an entirely unique query language for its particular data or file types. 

Other notable functionaUty includes transfer (via email, for example) of queries or partial 
queries to other users, and storage of queries or partial queries in a team repository for reuse. 

10 

Drawings 

Figure 1 is a block diagram of an exemplary environment for the invention. 

Figure 2 is a block diagram of an exemplary search system or architecture 200 in accord 
with the invention. 

15 Figure 3 is a flowchart of an exemplary method of operating a search system, such as 

system 200 in Figure 2, in accord with the invention. 

Figure 4 is a facsimile of an exemplary simple query window 400 in accord with the 
invention. 

Figure 5 is a facsimile of an exemplary advanced query window 500 in accord with the 
20 invention. 

Figure 6A is a facsimile of an exemplary query window 600, which is a variation of the 
window 500 in Figure 5. 

Figure 6B is a facsimile of an exemplary query window 600', which is a variation of 
window 600 in Figure 6A. 

25 Figure 7 is a facsimile of an exemplary graphical or pictorial query window 700, also in 

accord with the present invention. 

Detailed Description 

The following detailed description, which references and incorporates the drawings, 
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describes and illustrates one or more exemplary embodiments of the invention. These 
embodiments, offered not to limit but only to exemplify and teach the invention, are shown and 
described in sufficient detail to enable those skilled in the art to practice the invention. Thus, 
where appropriate to avoid obscuring the invention, the description may omit certain information 
5 known to those of skill in the art. 

The description includes three sections. The first describes an exemplary computer 
system environment for the invention. The second describes exemplary search system 
architecture, an exemplary method of operation, and exemplary user interface structures, all 
embodying various aspects of the invention. The third and concluding section summarizes some 
10 features and advantages of the exemplary embodiments. 

1. Exemplar/ Environment 

Figure 1 is a high-level diagram of an exemplary environment 100 having software 110 
and hardware 120 for hosting the invention as executable instructions, data, and/or electronic and 
mechanical components. However, other suitable environments and variations of the described 
15 environment are also possible and within the scope of the invention. 

Hardware components 120 are shown as a conventional personal computer (PC) 
including a number of components coupled together by one or more system buses 121 for 
carrying instructions, data, and control signals. These buses may assume a number of forms, 
such as the conventional ISA, PCI, and AGP buses. Some or all of the units coupled to a bus can 

20 act as a bus master for initiating transfers to other units. Processing unit 130 may have one or 
more microprocessors 131 driven by system clock 132 and coupled to one or more buses 121 by 
controllers 133. Internal memory systeml40 supphes instructions and data to processing unit 
130. High-speed RAM Hlstores any or all of the elements of software 110. ROM 142 
commonly stores basic input/output system (BIOS) software for starting PC 120 and for 

25 controUing low-level operations among its components. Bulk storage subsystem 150 stores one 
or more elements of software 110. Hard disk drive 151 stores software 1 10 in a nonvolatile 
form. Drives 152 read and write software on removable media such as magnetic diskette 153 and 
optical disc 154. Other technologies for bulk storage are also known in the art. Adapters 155 
couple the storage devices to system buses 121, and sometimes to each other directly. Other 
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hardware units and adapters, indicated generally at 160, may perform specialized functions such 
as data encryption, signal processing, and the like, under the control of the processor or another 
unit on the buses. 

Input/output (I/O) subsystem 170 has a number of specialized adapters 171 for 
5 connecting PC 120 to external devices for interfacing with a user. A monitor 172 creates a visual 
display of graphic data in any of several known forms. Speakers 173 output audio data that may 
arrive at an adapter 171 as digital wave samples, musical-instrument digital interface (MIDI) 
streams, or other formats. Keyboard 174 accepts keystrokes from the user. A mouse or other 
pointing device 175 indicates where a user action is to occur. Block 176 represents other input 

10 and/or output devices, such as a small camera or microphone for converting video and audio 
input signals into digital data. Other input and output devices, such as printers and scanners 
commonly connect to standardized ports 177. These ports include parallel, serial, SCSI, USB, 
Fire Wire, and other conventional forms. 

Personal computers frequently connect to other computers in networks. For example, 

15 local area network (LAN) 180 connect PC 120 to other PCs 120^ and/or to remote servers 181 
through a network adapter 182 in PC 120, using a standard protocol such as Ethernet or token- 
ring. Although Fig. 1 shows a physical cable 183 for interconnecting the LAN, wireless, optical, 
and other technologies are also available. Other networks, such as wide-area network (WAN) 
190 can also interconnect PCs 120 and 120', and even servers 181, to remote computers 191. 

20 Computers 181 and 191 have processors, storage, and communications equipment similar to 

those of PC 120, although usually of higher capacity. Fig. 1 illustrates a communications faciUty 
192 such as a pubUc switched telephone network for a WAN 190 such as an intranet or the 
Internet. PC 120 can employ an internal or external modem 193 coupled to serial port 177. 
Other technologies such as packet-switching ISDN, ATM, DSL, frame-relay are also available. 

25 In a networked or distributed-computing environment, some of the software 110 may be stored 
on the other peer PCs 120', or on computers 181 and 191, each of which has its own storage 
devices and media. 

Software elements 110 may be divided into a number of types whose designations 
overlap to some degree. For example, the previously mentioned BIOS sometimes includes high- 
30 level routines or programs which might also be classified as part of an operating system (OS) in 



other settings. The major purpose of OS 1 1 1 is to provide a software environment for executing 
application programs 1 12 and for managing the resources of system 100. An OS such as 
Windows® or Windows NT® from Microsoft Corp. commonly includes high-level application- 
program interfaces (APIs), file systems, communications protocols, input/output data 

5 conversions, and other fiinctions. 

Application programs 1 12 perform more direct fiinctions for the user, A user normally 
calls them expHcitly, although they can execute implicitly in connection with other applications 
or by association with particular data files or types. Modules 1 13 are packages of executable 
instructions and data, which may perform functions for OSs 1 1 1 or for applications 112. 

10 Dynamic link libraries (DLL) and class definitions, for instance, supply functions to one or more 
programs. 

Data 1 14 includes user data of all types, data generated and/or stored by programs, and 
digital data that third parties make available on media or by download for use in computer 120. 
Software elements can be embodied as representations of program instructions and data in a 
15 number of physical media, such as memory 140, non-volatile storage 150, and signals on buses 
183, 192, and so forth. 

2. Exemplary Search System Architecture 
Figure 2 shows an exemplary search system or architecture 200 in accord with the present 
invention. Architecture 200 includes a graphical user interface 202, a search application program 

20 interface (API) 204, search providers 204a, 204b, and 204c, and data stores 208a, 208b, and 
208c, which in the exemplary embodiment are implemented in C++ or COM. However, other 
embodiments implement the components as CORBA objects. Indeed, the invention is not 
limited to any particular form or class of implementations. In some embodiments, the data stores 
include one or more of the following types of data: files, folders, workspaces (akin to source- 

25 code-control (SCC) databases), bugs, problem reports, code defects, project tasks, test cases, test 
results, build scripts, build results, performance data, load/stress data, and in fact virtually 
anything related to software under development or the software development process itself 

In general, user interface 202 facilitates user definition of query structures and 
coramunication of these query structures to search API 204, which in tum communicates them 
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one or more of search providers 204a-204c. The search providers process the query structures 
and search one or more of data stores 208a-208c based on the query structures and return any 
search results to interface 202 via search API 204. 

More particularly, Figure 3 shows an exemplary flow chart 300 that provides further 
5 details of operating the exemplary search system in accord with the invention. Flow chart 300 
includes blocks 302-314, which are arranged serially in the exemplary embodiment. However, 
other embodiments of the invention may execute two or more blocks in parallel using two or 
more independent machines, two or more processors, or a single processor organized as two or 
more virtual machines, subprocessors, threads, fibers, or other altemative techniques. 

10 Additionally, other embodiments reorder, combine, divide, and/or omit the functions associated 
with one or more of these exemplary blocks. Moreover, still other embodiments implement the 
blocks as two or more specific interconnected hardware modules with related control and data 
signals communicated between and through the modules. Thus, the exemplary process flow is 
appUcable to not only software, but also firmware and hardware implementations. 

1 5 In process block 302, a user or device invokes a search command, such as a "find 

command," indicating a desire to find and retrieve certain files or data within files. In some 
embodiments, the search command retrieves data in the form of data records, conceptual objects 
,or other desired logical forms. On invocation of the search command, search API 204 
determines the query properties associated with one or more of the search providers to determine 

20 one or more query properties, as indicated in block 304. 

In some embodiments, this determination entails interrogating one or more of the search 
providers, each of which responds with one or more sets of data describing one or more of their 
respective query properties. Other embodiments rely on one or more of the search providers to in 
effect register one or more of their query properties with API 204 or some other object or 

25 resource accessible to API 204 or interface 202. In one variant of this registration, at least one 
search provider registers one or more its query properties as part of its installation into system 
200 and API 204 refers to these registered properties. An exemplary set of query properties 
includes a list of one or more data property names, query comparison operators, and a number of 
operands for each of the comparison operators, syntactic data types and data value type for each 

30 operand. In some embodiments, the query properties also include localization information about 



display strings. After receiving one or more set of query properties from the search providers, 
execution continues at block 306. 

Block 306 entails configuring and displaying (or otherwise manifesting) a user interface 
based at least in part on the set of query properties for one of the search providers. In the 

5 exemplary embodiment, this entails communicating one or more of the query properties for each 
of the search providers to the user interface. 

Based on one or more of these properties, the system configures and displays a graphical 
user interface having an appropriate set of entry fields, drop-down menus, and/or other 
conventional mechanisms to facilitate articulation or definition of one or more queries using the 

10 particular query properties of one or more of the search providers. (Figures 4, 5, 6A, 6B, and 7, 
which are discussed below, show several exemplary search windows that are configured based 
on discovered query properties of the search providers.) After definition of a query, the query is 
passed from the user interface to search API 204, possibly in a textual form similar to a SQL 
query or in the form of an XML document, which then executes block 308. In the exemplary 

15 embodiment, the search providers communicate a Ust of one or more searchable fields for its 
associated data stores. Each field has optionally associated legal values and valid operators, and 
each operator has associated information indicating the number, style, and type of permissible 
operands. The searching service also provides APIs to convert between a query tree, a SQL-like 
representation, XML, and other possible embodiments. 

20 Block 308 entails accepting the query and communicating it to one or more of the search 

providers. To this end, the exemplary embodiment forms a parse tree representative of the query 
and passes it by value or by reference to one or more of the search providers , Advantageously, 
the search provider doesn't need to parse SQL or XML. It has a structurally vahd parse tree of 
the query. This makes query generation much simpler. In many embodiments that pass or call 

25 byreference, the search provider is responsible for copying the data and ensuring that the source 
data remains unmodified. In contrast, the "pass or call by value" approach allows providers to 
annotate and modify as necessary. This approach is desirable because it allows the provider to 
modify the parse tree during query formation, optimizing or transforming the tree for the target 
search facility. 
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In the exemplary embodiment, search API 204 marshals the parse tree to the search 
provider. Services are also available to allow the search provider to marshal the parse tree to 
other search providers, processes, or computers. 

Unlike conventional search providers, one or more of the search providers in the 
5 exemplary embodiment do not require a parser. In some embodiments, at least one of the search 
providers includes a parser, which thereby allows sharing of any requisite parsing between search 
API 204 and the search provider. Some embodiments omit a parser altogether, relying on 
transfer of the query from API 204 to the search providers in some other form, such as an XML 
document. 

1 0 After passing of the query, or more precisely some data structure representative of the 

query, to one of the search providers, the exemplary method of operation continues at block 310. 
In block 310, one or more of the search providers searches its associated data store 208a, 208b, 
or 208c based on the parse tree or other structure representing the user-defined query. In the 
exemplary embodiment, one or more of the search providers receiving the parse tree remaps the 

1 5 parse tree according to its query properties to facilitate an optimal search of its associated data 
stores. For example, a tuple such as CreationDate Between Datel, Date 2, which identifies files 
(or more generally data objects) having a creation date between Datel and Date2 inclusive, can 
be remapped to a combination tuple, such as CreationDate >= Datel AND CreationDate <= Date 
2. Though this example is quite simple, the principle of query transformation allows for 

20 remapping arbitrarily complex and abstract operators and queries according to the query 
grammar of any number of search providers. 

Exemplary search providers expose query properties using "script name" and "display 
name." This allows the search providers to use locale-specific display names, while using locale- 
independent script names. Specifically, when an exemplary search provider generates a query 

25 from a parse tree, it uses the script name, but includes the display name as a column alias. Thus, 
the query tree points to structures that contain both the display name and the column alias, 
enabUng the search provider to choose the best one for the task at hand. This is also integrated 
into the SQL-hke language and can be integrated into other forms such as XML. 

Related functionality in the exemplary embodiment allows for the hierarchical layering or 

30 serial chaining of the search providers to answer a query. Specifically, the exemplary 



embodiment allows hand off of a query (or equivalent parse tree or XML document) from 
provider 306c to provider 306b and provider 306b to provider 306a, with the effect of provider 
306a fulfilling the query and the results reported back through provider 306c to the user interface 
via search API 204. This capacity to chain or layer search providers is without theoretical 
5 bound. 

After completion of the search, the results are returned as indicated in block 312. The exemplary 
embodiment retums results in the form of OLE DB rowsets. However, other embodiments return 
results as Active Data Object (ADO) recordsets (a wrapper around OLE DB) or in XML and 
XQL forms. Other embodiments use other data structures capable of holding multiple search 
10 results. 

Figures 4, 5, 6A, 6B, and 7 show three exemplary user-selectable types of query windows 
—simple, advanced, and graphical— which can be configured based on discovered query 
properties of one or more of search providers 206a-206c in Figure 2. Unlike conventional user 

1 5 interfaces that allow searching through two or more search providers, the query windows of the 
present invention provide users with a consistent experience as they switch from one source 
provider to another. To achieve consistency across multiple search providers, each query 
window in the exemplary embodiment includes at least one set of one or more user entry fields 
which remains constant from one search provider to the next. In the exemplary embodiments, 

20 consistency manifest as a set of four fields which have similar placement within the query 
windows not only for each service provider, but also for each style or type of query window. 

In particular. Figure 4 shows an example of a simple query window 400, which includes 
regions or areas 402, 404, and 406. Region 402 includes input fields 402a, 402b, 402c, and 402d 
with associated pull-down menus (not shown). (Some embodiments omit the pull-down menus 

25 and infer options from context.) In this exemplary embodiment, field 402a accepts entry of one 
or more team identifiers; field 402b accepts entry of one or more work-area identifiers; field 402c 
accepts entry of one or more folder identifiers. These identifiers generally designate a set of one 
or more data stores and/or files to be searched. In the exemplary embodiment, TEAM indicates 
an input area for identifying one or more servers or data spaces associated with one or more 

30 design or development teams. TYPE indicates an input area for identifying the type or types of 
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objects or data to search; WORK AREA indicates an input area for identifying one or more 
information collections to search; and FOLDER indicates an input area for further identifying the 
desired search scope within an identified WORK AREA. Adjacent region 402 is region 404. 
The exemplary embodiment reserves region 404 for interface commands. In the exemplary 

5 embodiment, one or more of the search providers communicate icons such as icons 404a, 404b, 
and 404c for association with region 404. Each icon has a meaning determined by the search 
providers and generally indicates the type of information being search. This embodiment 
demonstratessearching a single data type (for example, file or bug) per search. However, other 
embodiments could allow searching across two or more types. 

10 Region 406 includes input fields 406a and 406b, each having an associated pull-down 

menu. Region 406a accepts entry of a find string, and region 406b accepts entry of one or more 
look-in identifiers. The look-identifiers generally identify corresponding search spaces within 
one or more associated databases. Figure 5 shows an example of an exemplary advanced query 
window 500, which includes a region 502, a region 504, and a region 506. Region 502, like 

1 5 region 402 in Figure 4, includes input fields 502a, 502b, 502c, and 502d with associated pull- 
down menus (not shown). Region 504 includes a number of interface commands. Region 506 
allows users to define or enter one or more name-relationship-value expressions (or tuples) 
identifying desired data attributes. More precisely, region 506 includes an "and-or" combination 
column 506a, a name or field column 506b, and one or more value columns 504d. In generally, 

20 columns 506b, 506c, and 506d define one or more name-relationship- value tuples. For more 

than one tuple (or row), column 504a includes, a logical operation (such as "and," "or," or "not") 
which defines the logical relationship of the tuples. For example, the ordered expression 
"Product Equals TSIM" in the first row of region 406 identifies data having an associated 
Product identifier string "TSIM." The "And's" in the second and third row of column 506a 

25 indicate that the desired data also must satisfy the expressions "Assign_To Equals "KHardy" and 
Priorty Equals "High." 

Figures 6A and 6B show two related variation of window 600. In particular. Figure 6A 
shows an advanced query window 600 which includes an ahas 602 for a tuple or other query 
structure. Ahas 600 is in effect a proxy for a predefined tuple or combination of tuples. Figure 

30 6B shows window 600 after a user had clicked or otherwise selected to display the tuple 



underlying alias 602. The exemplary embodiment supports use of one or more aliases in a single 
query window. (Note that the grouping and hierarchical display are independent of the actual 
search provider and illustrate how canonical elements can be optimized using shared user- 
interface techniques.) 

5 Relatedly, the exemplary embodiment also faciUtates a user identifying and persisting a 

tuple or combination of tuples as an alias for future use. Moreover, it also allows communicating 
the alias and its underlying query structure to other users via electronic mail and/or persisting 
them to a repository for reuse by others. In persisting the query structure, a user has the option to 
associate with the query a projection list (which identifies the form of the resuUs), ordering 

10 information (for example, sort by size, date, etc), search provider, user-interface format 
parameters (such as, column widths, column ordering, and so forth. 

Figure 7 shows a graphical query window 700 that allows a user to define a query 
pictorially or to view a previously defined query as a graph. Window 700 includes a region 702, 
a region 704, and a region 706, which are analogous to the regions in the other windows. Region 

15 706 includes a structured query diagram noting the conditions (tuples) and groupings. Users can 
select items or groups of items and create new groupings. Also, new conditions can be added to 
the diagram using main or context menus. The exemplary embodiment supports in-place editing 
of the diagram. 

One particularly useful feature of user interface 202 and its provision of query windows 
20 such as those shown in Figure 4, 5, and 7, is the ability for a user to define all or part of a query 
in one style or type and to switch from one query window style to another, thereby gaining 
alternative views of the query structure. For example, a user could begin defining a complex 
query in an advanced query window, such as window 500 in Figure 5, and then switch, with the 
click of a mouse, to a graphical query window, such as window 700 in Figure 5, of the same 
25 query in a query diagram. Some embodiments indicate to the user when conversion from one 
query view to another is not logically feasible. 

Some embodiments of the invention support side-by-side parallel use of any combination 
of two of the three query window forms. Thus, as one builds a query in one form of query 
window, such as the advanced query window, an equivalent query structure manifests in another 
30 form of query window, such as the graphical query window, allowing a user to more readily 



switch back and forth between the two query windows. Additionally, the exemplary 
embodiments supports component copying and moving using "cut" and "paste" features. The 
copying and moving function across different search windows and across different user interface. 
For example, a set of elements in a graphical query can be selected and pasted into the advanced 
5 grid and the result will be a grid representation of the graphical query. 

Conclusion 

In furtherance of the art, the present inventors have devised an extensible and adaptively 
configurable user interface to facilitate a common user experience across two or more data 
classes and an extensible common query structure to allow expansion of a query language to 

10 meet the demands of new data classes. The exemplary embodiment includes a discovery 
mechanism for determining one or more query properties, such as object properties, query 
operators, and operands, of one or more search providers. The discovery mechanism supports 
adaptive reconfiguration of a user interface to expose the query properties of the search 
providers. The exemplary user interface includes first and second regions, with the first region 

15 having a set of input fields, which remains substantially constant over a set of two or more search 
providers, and the second region adaptive to the query properties of a select search provider. 
Other notable functionaUty includes transfer (via email, for example) of queries or partial queries 
to other users, and storage of queries or partial queries in a team repository for reuse. 

The embodiments described above are intended only to illustrate and teach one or more 

20 ways of practicing or implementing the present invention, not to restrict its breadth or scope. 
Only the following claims and their equivalents define the actual scope of the invention, which 
embraces all ways of practicing or implementing the concepts of the invention. 
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Claims 

1 . A method of operating a system including two or more search providers and a user 
interface having a first input region and a second input region, the method comprising: 
receiving information regarding one or more query properties from one or more of the search 

providers; 

configuring at least a portion of the second input region of the user interface based on one or more of 

the received query properties; 
receiving user input through the user interface to define a query; 
parsing the query to define a parse tree; 
passing the parse tree to at least one of the search providers; 

transforming the parse tree based on query properties of one of the search providers; and 
conducting a search based on the transformed parse tree. 

2. The method of claim 1 , wherein receiving information regarding one or more query 
properties comprises receiving information regarding one or data object properties; one or more 
comparison operators, and one or more operands for each of the one or more comparison 
operators. 

3 . The method of claim 1 , wherein configuring at least a portion of the second input region 
of the user interface based on one or more of the received query properties comprises defining 
and displaying one or more input fields for one or more of the received properties. 

4. The method of claim 1, wherein passing the parse tree to at least one of the search 
providers comprises passing the parse tree by value to one of the search providers. 

5. The method of claim 1 further comprising electronically transferring at least a portion of 
the query to one or more other users. 

6. The method of claim 1, further comprising copying at least a portion of the query to a 
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repository for use by other users. 

7. A system comprising: 

a graphical user interface having a first input region and a second input region for defining a 
query; 

two or more search providers; 

means for receiving information indicating one or more query properties from one or more of the 
search providers; 

means for configuring at least a portion of the second input region of the user interface based on one 

or more of the received query properties; 
means for receiving user input through the user interface to define a query after reconfiguring at least 

a portion of the second input region; 
means for parsing the query to define a first parse tree; 
means for passing the parse tree to at least one of the search providers; 

means for deriving a second parse tree based on query properties of one of the search providers; and 
means for searching a database based on the second parse tree. 

8. The system of claim 7, wherein the means for deriving the second parse tree is within 
one of the two or more search providers. 

9. The system of claim 1, wherein the means for conducting a search based on the 
transformed parse tree is within one of the two or more search providers. 

10. A method of operating a system including two or more search providers and a user 
interface, the method comprising: 

receiving information regarding one or more query properties firom one or more of the search 
providers; and 

configuring at least a portion of the user interface based on one or more of the received query 
properties. 



15 



11. The method of claim 1 0, wherein receiving information regarding one or more query 
properties comprises receiving information regarding one or data object properties; one or more 
comparison operators, and one or more operands for each of the one or more comparison 
operators. 

12. The method of claim 10, wherein configuring at least a portion of the user interface based 
on one or more of the received query properties comprises defining and displaying one or more 
input fields for one or more of the received properties. 

13. A method of operating a system including two or more search providers and a user 
interface, the method comprising: 

receiving information regarding one or more query properties fi-om one or more of the search 
providers; and 

communicating a query based on one or more of the received query properties to one or more of the 
search providers. 

14. A method of operating a system including a user interface and one or more search 
providers, the method comprising: 

receiving input through the user interface to define a query; 

parsing the query to define a parse tree; and 

passing the parse tree to at least one of the search providers. 

15. The method of claim 14, wherein passing the parse tree to at least one of the search 
providers comprises passing the parse tree by value to one of the search providers. 

16. A method of operating a system including a user interface and two or more search 
providers, the method comprising: 

passing a parse tree representation of a query to a first one or the search providers; 

passing a parse tree representation of the query from the first one of the search providers to a second 
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one of the search providers; and 
transforming the parse tree representation of the query from the first one of search providers, based 
on query properties of one of the second one of the search providers. 

17. A method comprising: 

receiving a signal indicating invocation of a search or find command; 
displaying a first part of a graphical user interface in response to receiving the signal; 
receiving information regarding one or more query properties from one or more search providers; 
and 

displaying a second part of the graphical user interface based on the received information 
regarding the one or more query properties. 

18. A method comprising 

obtaining information regarding query definition forms for one or more search providers; 
defining a graphical user interface based on the obtained information regarding query 
definition forms for at least the one search provider. 

19. An extensible search architecture for a computer system, comprising: 

means for determining query properties of two or more search providers; and 

means for communicating queries based on the determined query properties of the search 

providers to one or more of the search providers. 

20. An extensible search architecture for a computer system, comprising: 
a graphical user interface; 

two or more search providers; and 

an interface coupled between the two or more search providers and the graphical user interface 
and adapted to communicate information regarding query definition forms from one or more of 
the search providers to the graphical user interface or information regarding one or more queries 
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from the graphical user interface to the search providers. 

21. A method for providing a unified user interface to two or more search providers, each 
adapted to search a different data store and each having one or more unique query operators or 
query-definition fields, the method comprising: 

identifying at least the unique query operators and query-definition fields supported by 
each search provider; 

displaying a user interface that allows definition of a query based on one or more of the 
unique query operators or query-definition fields; and 

processing the query by passing information regarding the one or more unique query 
operators and query-definition fields in the query to at least one of the search providers. 

22. The method of claim 21, wherein identifying at least the unique query operators and 
query-definition fields supported by each search provider comprises receiving information from 
each search provider identifying its unique query operators and query definition fields. 

23 . The method of claim 2 1 , wherein displaying a user interface that allows definition of a 
query based on one or more of the unique query operators or query-definition fields comprises 
displaying the one or more unique query operators or query-definition fields. 

24. The method of claim 21 , wherein processing the query by passing information regarding 
the one or more unique query operators and query-definition fields in the query to at least one of 
the search providers comprises passing a parse tree based on the query to at least one of the 
search providers. 

25. A computer readable medium having executable instructions encoded thereon 
comprising: 

a plurality of search providers, each adapted to search at least one data store using a 
supported set of search operators and a supported set of search fields; 
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a configurable user interface having two or more interface elements which allow 
construction of a query using any of the set of supported search operators and search fields from 
any of the plurality of search providers; and 

a search application program interface between the configurable user interface and the 
plurality of search providers, the search application program interface adapted to provide 
information regarding the supported set of search operators and search fields for each of the 
search providers so that the user interface can be configured to allow access to search operators 
and search fields supported by any of the plurality of search providers. 

26. The medium of claim 25, wherein one or more portions of the search providers, the user 
interface, or the search application program interface are implemented in accord with COM.. 

27. The medium of claim 25, wherein one or more of the search providers are implemented in 
an object-oriented programming language. 

28. The medium of claim 25, wherein one or more of the search providers is adapted to 
search two or more data stores. 

29. The medium of claim 25, wherein the plurality of search providers includes at least three 
search providers. 

30. The medium of claim 25, wherein the pluraUty of search providers includes a first search 
provider for searching bug files, a second search provider for searching link files, and a third 
search provider for searching software component files. 
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31.. A method of operating a graphical user interface for defining queries, the method 
comprising: 

receiving user input defining at least a portion of a query, through a table-style interface window; 
and 

displaying a diagrammatic- or keyword-style interface window based on the query. 

32. A method of operating a graphical user interface for defining queries, the medium 
comprising: 

displaying a query in a form of a diagram or a table within a first window of the graphical user 
interface; and 

displaying the query in a different form within a second window of the graphical user interface. 
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Abstract 

Most search engines, include user interfaces and query languages which are tailored for use with 
specific file types. Thus, a user interface for searching one type file can be quite different than an 
interface for searching another file type. Disparate user interfaces are troublesome since users 
must continually reorient themselves as they switch firom interface to interface to initiate 
searches for different file types. Additionally, many of these user interfaces use different query 
languages and structures, which are not generally adaptive to new file types and query language 
features. Accordingly, the present inventors developed an adaptively configurable user interface 
to facilitate a common user experience across two or more databases and an extensible common 
query structure to allow expansion of a query language to meet the demands of new file types. 
An exemplary embodiment includes a discovery mechanism for determining query properties of 
search providers, thereby facihtating adaptive configuring of a user interface to expose the 
determined query properties. An exemplary embodiment of the user interface includes a portion, 
which remains relatively constant across two or more search providers to reduce user 
disorientation. 
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§1.56 Duty to disclose information material to patentability. 



(a) A patent by its very nature is affected with a public interest. The public interest is best served, and the most effective patent 
examination occurs when, at the time an appUcation is being examined, the Office is aware of and evaluates the teachings of all information 
material to patentability. Each individual associated with the filing and prosecution of a patent application has a duty of candor and good 
faith in dealing with the Office, which includes a duty to disclose to the Office all information known to that individual to be material to 
patentability as defined in this section. The duty to disclose information exists with respect to each pending claim until the claim is canceled 
or withdrawn from consideration, or the application becomes abandoned. Information material to the patentability of a claim that is canceled 
or withdrawn from consideration need not be submitted if the information is not material to the patentability of any claim remaining under 
consideration in the application. There is no duty to submit information which is not material to the patentability of any existing claim. The 
duty to disclose all information known to be material to patentability is deemed to be satisfied if all information known to be material to 
patentability of any clahn issued in a patent was cited by the Office or submitted to the Office in the manner prescribed by §§ 1 .97(b)-(d) and 
1 .98. However, no patent v^ll be granted on an application in connection with which fraud on the Office was practiced or attempted or the 
duty of disclosure was violated through bad faith or intentional misconduct. The Office encourages applicants to carefully examine: 

(1) prior art cited in search reports of a foreign patent office in a coimterpart application, and 

(2) the closest information over which individuals associated with the filing or prosecution of a patent apphcation believe any 
pending claim patentably defines, to make sure that any material information contained therein is disclosed to the Office. 

(b) Under this section, information is material to patentability when it is not cumulative to information already of record or being 
made of record in the application, and 

S (1) It establishes, by itself or in combination with other information, a prima facie case of unpatentability of a claim; or 
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